Additional findings (outside current diff — PR may have been updated during review):

• 🟡 docs/migration/support-2026-07-28.md:486-491 — The claim that "the exported *Schema constants validate the neutral model and reject it as an unknown key" overgeneralizes: only EmptyResultSchema is strict (ResultSchema.strict()), while ResultSchema itself and the other result schemas listed in this bullet (CallToolResultSchema, GetPromptResultSchema, …) are loose-passthrough ResultSchema.extend(...) builds, so parsing a frame carrying resultType with them succeeds and keeps the field. Suggest scoping the rejection claim to EmptyResultSchema (matching the guide's own wire-codecs table, which says guards "validate neutral shapes (loose passthrough)") or restoring the previous neutral wording.

  Extended reasoning...

  What the bug is. The rewritten bullet under "Wire-only members hidden from public types" (docs/migration/support-2026-07-28.md, lines 486–491) lists Result, CallToolResult, GetPromptResult as examples and then states that "the exported *Schema constants validate the neutral model and reject it as an unknown key." The plural subject ("the exported *Schema constants") in a bullet that just enumerated those result types reads as a claim about all of them — but the rejection behavior only exists for EmptyResultSchema.

  What the code actually does. In packages/core-internal/src/types/schemas.ts:

  • ResultSchema is z.looseObject({...}) (line 92), with a comment explicitly noting that resultType is deliberately NOT modeled in the neutral schemas — it lives only inside the 2026-era wire codec.
  • EmptyResultSchema = ResultSchema.strict() (line 180) is the only strict result schema; it alone rejects unknown keys such as resultType.
  • Every other exported result schema — GetPromptResultSchema (line 1229), ListToolsResultSchema (line 1371), CallToolResultSchema (line 1378), CreateMessageResultSchema, etc. — is built with ResultSchema.extend(...) (or PaginatedResultSchema.extend(...)), which retains the loose catchall in zod 4.

  Step-by-step proof. Take a raw 2026-era wire frame's result object: { resultType: 'complete', content: [{ type: 'text', text: 'hi' }] }. (1) CallToolResultSchema.parse(obj) succeeds — CallToolResultSchema is ResultSchema.extend({ content: ..., ... }), and the loose base passes resultType through unchanged, so the parsed value still carries resultType: 'complete'. (2) The same is true for GetPromptResultSchema, ListToolsResultSchema, and the rest. (3) Only EmptyResultSchema.parse({ resultType: 'complete' }) throws, because .strict() rejects unknown keys. So the documented behavior — rejection as an unknown key — holds for exactly one of the schemas the bullet's subject covers.

  Why it matters. This bullet is targeted at v2-alpha migrators who previously read resultType directly. A migrator who validates raw wire frames with e.g. CallToolResultSchema and trusts this sentence will expect a parse failure on a frame carrying resultType (and may rely on that for traffic classification or sanitization); the parse passes and the field flows through. The sentence also conflicts with the same guide's own wire-codecs table a few lines up (line ~463), whose last row says guards/schemas "validate neutral shapes (loose passthrough); validate raw wire traffic with a transport-level parse." The pre-PR wording ("The wire schemas keep parsing it, and the protocol layer consumes it before results reach your code") made no rejection claim, so this inaccuracy is introduced by the diff. The trailing parenthetical pointing to "the EmptyResultSchema row" softens but does not scope the plural-subject sentence.

  Why nothing else catches it. docs:check and snippet sync validate links and code blocks, not prose claims about schema strictness, and no verifier objected — all four confirmations independently checked schemas.ts and agreed.

  How to fix. Scope the claim to the one strict schema, e.g.: "…the exported *Schema constants validate the neutral model and pass unknown keys through — only EmptyResultSchema rejects resultType as an unknown key (the EmptyResultSchema row in the Per-era wire codecs table)." Or simply restore the previous neutral wording. One-clause change, docs only.